PreviousNextTracker indexSee it online !

(158/314) 3406680 - Sidekick filter unusable without mouse

If I type some text in Sidekick filter textbox, I see the asset tree narrows to match the criteria. If I use mouse to choose the asset, works ok. But if I press VK_DOWN, then a strange behaviour takes place. I travel through the invisible assets. If I press VK_DOWN enough times, then I can highlight a visible item, but obviously invisible items are travelled too. That makes keyboard travelling impossible.

To see the bug, load the following file and have it parsed by ctagssidekick (other c parsers should show the same issue).

int x()
{
}

int y()
{
}

If you fill the filter with "y", and use arrows to travel through the list, you'll notice that "x" is being travelled too.

Desired behaviour: omit invisible assets when travelling the list through keyboard.

Another similar details that could be done in the same time:
1. Pressing enter in the filter box should place the focus in asset tree.
2. When asset list is focused, I would prefer keyboard hits be serviced by asset tree, not by filter. I would be able to quickly select the entry even with a filter on. I like very much the behaviour of asset list when the filter is off, so it would be good to join both functionalities: filtering and quick access by beginning letters.

Submitted jarekczek - 2011-09-09 - 07:51:58z Assigned nobody
Priority 3 Category None
Status Open Group None
Resolution Accepted Visibility No

Comments

2011-09-09 - 08:07:30z
jarekczek
XP, 4.4.1
2011-09-20 - 18:01:45z
jarekczek
Workaround: use arrows with Control
2011-09-20 - 18:20:10z
daleanson
Do you think this is simply a documentation problem?
2011-09-20 - 23:50:47z
ezust
I can confirm this bug. If I filter on y, and use arrow keys to travel through the list, the cursor becomes invisible as the it hits "x", but it's definitely on one of the filtered nodes. After another VK_DOWN, it hits "y" and cursor is visible again.

2011-09-20 - 23:52:03z
ezust
but if we document it clearly, then it won't be a bug anymore. Perhaps this is just how java trees work?
2011-09-22 - 06:39:15z
jarekczek
I insist this is a bug. From next/prevLeaf the bug is removed by an additional loop. I'm ready to apply a similar loop to next/prev, but first I reported inconsistency between next/prevLeaf in:
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=3411490&group_id=588

After that resolution is accepted I'll be sure what the condition of "visibility" is. Of course I don't mind you fix it yourselves.

Attachments

2011-09-09 - 07:51:59z
jarekczek
main.c

simple file with x and y functions